Method, devices and system to control provision of voice services in mobile communications networks

ABSTRACT

A system, method and devices for controlling provision of a voice service at a terminal of a first mobile communications network based on the expected quality of service. The presented embodiments improve the VoIP service performance in mobile telecommunication networks solving the problems of current VoIP services, providing to the user a good quality, especially in low coverage or congestion scenarios (reaching a similar quality than the CS voice calls in the same situations).

TECHNICAL FIELD OF THE INVENTION

The invention relates to the provision of voice services based onexpected quality of service to terminals in a mobile communicationnetwork.

BACKGROUND TO THE INVENTION

Long Term Evolution (LTE) is a standard for wireless communication ofhigh-speed data for mobile phones and data terminals. It is partiallybased on previous network technologies (GSM/EDGE, UMTS . . . ),increasing the capacity and speed using a different radio interfacetogether with core network improvements. The standard is developed bythe 3GPP (3rd Generation Partnership Project) and is specified in itsRelease 8 document series, with enhancements described in Releases 9, 10and 11. LTE is considered by many to be a Fourth Generation (4G)technology, both because it is faster than 3G, and because, like theInternet, LTE uses a flat “all-IP” architecture where all information,including voice, is handled as data. LTE provides high and improvespectral efficiency in networks, allowing carriers to provide more dataand voice services over a given bandwidth.

As it is well known in the prior art, there is a main classification forthe voice services offered in mobile communications network, Voice overcircuit switching (CS) services and Voice over Internet Protocol (IP)services.

Voice over circuit switching (Voice over CS) refers to the methodologyfor offering a voice communication service over a CS communication. Itis used to offer voice services over 2G and 3G mobile networks. Circuitswitching (CS) is a methodology of implementing a telecommunicationsnetwork in which two network nodes establish a dedicated communicationchannel (circuit) through the network before the nodes may communicate.The circuit guarantees the full bandwidth of the channel and remainsconnected for the duration of the communication session. The circuitfunctions as if the nodes were physically connected as with anelectrical circuit.

Voice over Internet Protocol (VoIP) is a methodology for the delivery ofvoice communications and multimedia sessions over Internet Protocol (IP)networks, such as the Internet. It differs from Voice over CS servicesin that it uses the PS (Packet Switching) technology to deliver theservice, as opposed to the CS service. In packet switching, instead ofbeing dedicated to one communication session at a time, network linksare shared by packets from multiple competing communication sessions,resulting in the loss of the quality of service guarantees that areprovided by circuit switching.

VoLTE (Voice over IP over LTE) is a Voice over IP service provided bythe LTE networks, it is based on the IP Multimedia Subsystem (IMS)network, with specific profiles for control and media planes of voiceservice on LTE as defined by the GSM Association (GSMA) in PRD IR.92. Inthis approach the voice service (control and media planes) is deliveredas data flows within the LTE data bearer. This would mean that there isno dependency on (or ultimately, requirement for) the legacy CircuitSwitching voice network to be maintained.

VoLTE is a technology already available and working commercially (e.g.in countries like South Korea). In situation where LTE coverage is notas good as 3G coverage, VoLTE should be able to smoothly perform ahandover (without interruption) of the voice call to a 3G or 2G networksin case of poor LTE signal quality. This is done, for example, by theSingle Radio Voice Call Continuity (SRVCC) service which provideshandover functionality from IMS PS domain (VoLTE) to 3G or 2Gcommunication networks with VoIP technology using one single radiosignal at a time. FIG. 1 shows schematically some of the nodes involvedin said SRVCC service. The service is based on a SRVCC applicationserver (SRVCC-AS) responsible for anchoring voice call and managinghandover (through the CSCF) on request from a node (e.g. the MobilityManagement Entity, MME) of the LTE access network (Evolved UTRAN). ForSRVCC from the LTE access network (E-UTRAN) to 2G/3G access network(UTRAN/GERAN), the MME first receives a handover request from theE-UTRAN (e.g., from an e-Node B) with the indication that this is forSRVCC handling. Then the MME triggers the SRVCC procedure with the MSCServer (enhanced for SRVCC) via the Sv interface reference point. TheMSC Server then initiates the session transfer procedure with the IMSnetwork (e.g., with the SRVCC Application Server) and coordinates itwith the CS handover procedure to the target cell. Then, the MSC Serversends a handover Response to the MME, which includes the necessary CS HOcommand information for the UE to access the UTRAN/GERAN. If there is aPS handover, information is sent to the SGSN via the S3 interface.

The drawback of making the handover to 3G/2G is losing some of the addedservices only possible over IMS, like the Video-telephony over IP.

When it is not possible to continue using the VoLTE service, analternative solution would be to use VoIP over HSPA in a 3G network, inorder to provide a service to the end user as similar as possible to theVoLTE (e.g., provided over IP).

VoIP over HSPA (VoHSPA) refers to the methodology for offering a VoIPservice over an HSPA mobile network through the PS service. HSPA (HighSpeed Packet Access) is a packet-based data system, evolved from andbackward compatible with Release 99 (Rel'99) WCDMA systems, whichprovides high-speed data transmission (up to 21 Mbps over a 5MHzbandwidth when using 64QAM modulation) in 3rd generation mobiletelecommunication networks utilizing the WCDMA protocols, bringingimprovement in terms of speed and latency reduction and enhancingsupport for high-performance packet data applications. HSPA improves thedownlink by introducing HSDPA (High Speed Downlink Packet Access), whichis based on shared channel transmission and its key features are sharedchannel and multi-code transmission, higher-order modulation, shorttransmission time interval (TTI), fast link adaptation and schedulingalong with fast hybrid automatic repeat request (HARQ). Uplink is alsoimproved with HSUPA (High Speed Uplink Packet Access). Enhanced Uplinkadds a new transport channel to WCDMA, called the Enhanced DedicatedChannel (E-DCH). An enhanced uplink and downlink create opportunitiesfor a number of new applications including for example, VoIP, uploadingpictures and sending large e-mail messages. The enhanced uplinkincreases the data rate (up to 5.8 Mbit/s), the capacity, and alsoreduces latency. The enhanced uplink features several improvementssimilar to those of HSDPA, including multi-code transmission, shortTransmission Time Interval (TTI), fast scheduling and fast HybridAutomatic Repeat Request (HARQ).

There is a voice over HSPA IMS service defined by the GSM association inthe PRD IR.58, similarly to the PRD IR.92 for VoLTE. In PRD IR.58, anumber of HSPA, (Evolved) Packet Core, IMS core, and UE features whichare considered essential to launch interoperable IMS based voice onHSPA, are defined. This document is based on the IMS Voice and SMSprofile described in PRD IR.92 and the service is based on theConversational PS Radio Bearers. This type of bearers providesGuaranteed Bit Rate and therefore absolute quality of service to fulfilthe voice communications needs and also the possibility of doing SRVCCto the 2G/3G CS domain as explained before for VoLTE.

However the Conversational PS Radio Bearers are not available yet inmost of the network infrastructure vendors and terminals manufacturers.So, the only possibility today to provide Voice over IP over HSPA iswith a best effort PS Interactive or Background bearer. So the currentlyprovided VoIP over HSPA service has a twofold problem:

-   -   This service is not feasible in 2G due to the poor performance        in terms of low bit rate and high latency of the 2G network, so        the VoIP over HSPA calls will be dropped when losing 3G coverage        without possibility of doing a handover like SRVCC towards the        2G CS service. And given that most of the 3G coverage is        provided with 2100 MHz band, the coverage and performance of        VoIP over HSPA in some areas of bad coverage will be poor.    -   Moreover, as stated above, Voice over IP over HSPA service is        provided using PS Interactive or Background bearers without any        QoS Guaranteed. That is, it is always “best effort” (the service        is provided with the best possible quality but without        guaranteeing any minimum QoS). Then, in case of congestion the        Voice over IP calls will be seriously affected due to latency,        retransmission and low throughput. Today there are no solutions        for bad VoIP performance due to low 3G coverage or high 3G        congestion to reach a similar quality than the CS voice calls in        the same situations.

The only solution to avoid the lack of 2G VoIP service is to deployUMTS900 that has a similar coverage than the 2G but the problem is thatUMTS900 is not deployed everywhere. Another solution is to deploy LTE inthe 1800 and 800 bands but it might take several years and a biginvestment to deploy in every site of the network.

To solve the problem of high congestion, the only measure taken now isto prioritize the VoIP traffic with respect to the rest of the traffic.But this is not working very well in very high congested scenarios whereall the “best effort” services suffer a lot. Currently, only CSGuaranteed service can resist this type of scenario.

Hence, there is a need to efficiently provide a user in a mobilecommunication network with the best voice service (e.g. fast, supportingmultimedia) possible, providing at the same time a good quality,especially in low coverage or congestion scenarios, solving the problemsof the VoIP over HSPA services currently used. The proposed embodimentsof the invention stated below will provide mechanisms to achieve, amongothers, these advantages.

SUMMARY OF THE INVENTION

The present invention solves at least the aforementioned problems, andtechnical advantages are generally achieved, by disclosing a method,system and devices for use in a mobile telecommunication network, whichimproves the performance of prior art solutions.

It is proposed a technique that, based on an expected quality of service(which can be calculated in a cell basis or in a terminal basis)associated with a first type of voice service, it determines whether ornot to allow the first type of voice service on a terminal. Hence, thereis allowance or not of the first type of voice (end to end) service.

In the present text, the term “service” usually means an End-to-EndService. So, when there is a change from a first voice service to asecond voice service according to the present invention, it implies achange in the Core Network domain (e.g. PS IMS network to CS MSC), inthe signaling used (traditional CS Signaling versus SIP signalling), andthe radio bearer could be the same for both (HSPA) or different (HSPAvs. R99-CS).

In other words, a change of “service” as disclosed in the presentinvention is a change in the “end-to-end” service rather than in a radiobearer as in the prior art solutions. As it will be shown in FIG. 2, theRadio Bearer is the connection/channel between the Radio Access Network,RAN, (specifically the Radio Network Controller, RNC) and the terminal.

In FIG. 2, it is shown a schematic diagram showing different type ofbearers in the 3GPP architecture according to the 3GPP standard(Technical Specification TS 23.107), where an overview of the differentLevels of Quality of Service (QoS) is presented. Network Services areconsidered end-to-end, this means from a Terminal Equipment (TE) toanother TE. An End-to-End Service may have a certain Quality of Service(QoS) which is provided for the user of a network service. It is theuser who decides whether he is satisfied with the provided QoS or not. Abearer service includes all aspects to enable the provision of acontracted QoS. These aspects are among others the control signalling,user plane transport and QoS management functionality. On its way fromone terminal (TE) to another terminal the traffic pass through differentbearer services of the network(s). A TE is connected to the UMTS networkvia a Mobile Termination (MT) point. As shown in FIG. 2, theEnd-to-End-Service used by the TE will be performed using a TE/MT LocalBearer Service, a UMTS Bearer Service, and an External Bearer Service.TE/MT Local Bearer Service and the External Bearer Service are outsidethe scope of the UMTS network. The UMTS bearer has two parts: the RadioAccess Bearer Service and the Core Network Bearer Service. The RadioAccess Bearer Service provides confidential transport of signalling anduser data between MT and Core Network (CN) Edge Node with the QoSaccording to the negotiated UMTS Bearer Service or with the default QoSfor signalling. The Core Network Bearer Service of the UMTS core networkconnects the UMTS CN Edge Node with the CN Gateway to the externalnetwork. The role of this service is to efficiently control and use thebackbone network in order to provide the contracted UMTS bearer service.The Radio Access Bearer Service is performed by a Radio Bearer Serviceand a RAN (Radio Access Network) Access Bearer Service. The Radio BearerService (supported by the Physical Radio Bearer Service) covers all theaspects of the radio interface transport. The RAN Access Bearer Service(supported by the Physical Bearer Service) provides the transportbetween the Radio Access Network and the Core Network.

There are many different types of bearers depending on the technologyused, for example, the HSDPA, R99 12.2 Kbps, and the HSUPA (in order torefer to both HSUPA and HSDPA bearers, the term HSPA is used). Thechange of radio bearer is usually done many times in a network due tocongestion or radio conditions. In some prior art solutions, what it isproposed it is only a change in radio bearer according to the serviceconditions.

For example, document US2010215034 describes a method in which, based onconditions associated with the voice call, a different transportmechanism for the voice call is selected. In said document, two bearersbelonging to the same domain (CS domain) are switched/reconfigured basedon said conditions. So either the service with the well-known Release 99Dedicated Channel (CS-R99) is provided or CS service over an HSPAbearer, CS-HSPA is provided. However, said document does not disclosethe fact that, based on expected quality of a call type on a firstdomain (PS), a decision is made on which call type and domain to allow(as proposed by the present invention) and, in said document, the CNconnection (Radio Access Bearer and CN Bearer) is not changing.Moreover, CS-HSPA is almost not used in the current commercial mobilecommunications networks because most of the terminals and someinfra-vendors do not implement it.

According to a first aspect of the present invention, it is provided amethod of controlling provision of a voice service for a terminal in amobile communications network, the method comprising: determining, basedon at least a service parameter associated with a first type of voiceservice, whether to enable use of said first type of voice service forthe terminal.

Said service parameter may be associated with at least one cell of themobile communications network. The method may further comprise:disabling, at the least one cell, the first type of voice service whenthe service parameter is indicative of insufficient expected quality ofservice in the event of use of the first type of voice service by theterminal.

In order to perform the disablement, said first type of voice servicemay be configured at a network node (e.g. a Radio Network Controller) asdisabled for said at least one cell.

Said service parameter associated with at least one cell, which isindicative of the expected quality of service for the first type ofvoice service may be the congestion detected in said at least one cellor optionally the service parameter can be calculated based at leastpartially on the quality of service of the last M calls using the firsttype of service in said at least one cell, where M is a designparameter.

Said service parameter may be associated with the terminal. The methodmay further comprise: disabling, at the terminal, the first type ofvoice service when the service parameter is indicative of insufficientexpected quality of service for the terminal in the event of use of thefirst type of voice service.

In order to perform the disablement, said first type of voice servicemay be configured at a network node (e.g. a Home Subscriber Server) asdisabled for said terminal (or for the subscriber associated to saidterminal).

Said service parameter associated with the terminal, which is indicativeof the expected quality of service for the first type of voice servicefor the terminal may be calculated based at least partially on thequality of service of the last N calls of the terminal using the firsttype of service, where N is a design parameter. Said quality of servicemay be based at least partially in at least on one of the following KeyPerformance Indicators for said terminal: Drop call rate ratio, failureratio, MOS, Throughput or Latency.

So said service parameter, which is indicative of the expected qualityof service for the first type of voice service, may be a qualityparameter associated with at least a part of the mobile communicationsnetwork. As it has been explained in the previous paragraphs, it can befor example associated to a cell (e.g. the congestion detected in saidcell) or to a single terminal (e.g. the quality of service of the last Ncalls of the terminal using the first type of service).

In both cases (service parameter associated to a cell or to theterminal), if the first type of voice service is determined to bedisabled, a second voice service (e.g. a voice over CS service) will beprovided at the terminal.

As stated before, the disabling of the first type of voice service (atcell or at terminal level) is made when the service parameter isindicative of insufficient expected quality of service in the event ofuse of the first type of voice service by the terminal. Said use can bea current use or a future use or, in other words, said expected qualitymay be determined for a real current scenario (based on qualityinformation of a current use of said first type of service by saidterminal) or for an hypothetical future scenario.

For example, if the measured quality for a current call using the firsttype of voice service in a terminal is bad, then said first type ofservice is disabled during the call because it is not working properly.That is, in this case, the service is disabled because the expectedquality of service in the event of current use of the first type ofvoice service by the terminal is insufficient. For example, during acall in a terminal using VoLTE, the application may decide to “disable”it based on the fact that the current quality of VoLTE is not goodenough, and therefore it will be “expected” an insufficient quality ofservice for VoLTE. Then, the current call is handover to another service(e.g. VoHSPA). When the terminal will try to connect again using VoLTE,said service will not be allowed and the terminal will be allowed to useVoHSPA only (at least the service has been enabled again because thequality conditions have changed).

In another example, based on the congestion detected on the cell or inthe KPIs measured for the terminal or in the quality of the last Ncalls, it is assumed that if the terminal is going to switch to saidfirst type of service (future use), the quality of service “expected”for the terminal would not be good enough, so the first type of serviceis disabled. That is, in this case, the service is disabled because theexpected quality of service in the event of a future use of the firsttype of voice service by the terminal is insufficient.

The first type of voice service may be any known voice service as forexample, a Voice over IP over HSPA service or a Voice over LTE, VoLTE,service..

In an embodiment, in the event of a handover of a voice call from afirst cell of the mobile communications network to a second cell of themobile communications network, the method further comprises: switching acurrent voice service to the first type of voice service if the firsttype of voice service is enabled at the second cell and/or at theterminal. In this case the method may be performed by an e-node B of themobile communications network.

In another embodiment, in the event of a handover from a first cell ofthe mobile communications network to a second cell of the mobilecommunications network, the method further comprises switching a currentvoice service to a second type of voice service if:

-   -   (i) the expected quality of service for the terminal in the        event of use of the first type of voice service by the terminal        is insufficient (for example, a first cell, LTE cell, is to hand        over to a second cell, 3G cell, but the customer 3G quality is        not sufficient. Accordingly, the switch is to a second type of        voice service (e.g., 3G CS or 2G CS); or    -   (ii) the first type of service is disabled at the second cell        (for example, a first cell (LTE cell) is to hand over to a        second cell (3G cell), but the second cell is marked as “no        VoHSPA” (i.e., the first type of voice service is disabled.        Accordingly, the switch is to a second type of voice        service(e.g., 3G CS or 2G CS).

The first cell may use a first Radio Access Technology, RAT (e,g, anLTE-based RAT) and the second cell may use a second RAT (e.g. an3G-based RAT).

The determination whether to enable use of said specific voice serviceat the terminal in the mobile communications network may be made as wellin order to establish a new voice call for said terminal using saidfirst type of voice service. In this case the method may be performed bya Radio Network Controller of the first mobile communications network.

According to a second aspect of the invention, it is provided a networkelement for controlling provision of a voice service for a terminal in amobile communications network, the network element being configured to:determine, based on a service parameter associated with a first type ofvoice service, whether to enable use of said first type of voice servicefor the terminal.

According to a third aspect of the invention, it is provided a systemfor controlling provision of a voice service for a terminal in a mobilecommunications network, the system being configured to: determine, basedon a service parameter associated with the first type of voice service,whether to enable use of said first type of voice service for theterminal.

The network element or the system may be also configured to perform thesteps of any of the above disclosed methods.

According to a fourth aspect of the invention, it is provided a terminalfor use in the previously mentioned system, wherein the terminalcomprises at least one functionality configured to perform therespective steps of any one of the above disclosed methods

It will be understood that any of the features described herein inconnection with the network element can equally be provided as steps inthe method of the first aspect and vice versa. Beneficially, the presentinvention also provides a computer program configured when operated by aprocessor to perform any one of the above-described methods and adigital data storage medium is also provided encoding amachine-executable program of instructions to perform any of the methodsdisclosed.

Any combination of the features described in connection with either thefirst, second or third aspects are also provided, even if not explicitlydisclosed.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may be put into practice in various ways, one of whichwill now be described by way of example only and with reference to theaccompanying drawings in which:

FIG. 1 shows a schematic block diagram of the SRVCC service.

FIG. 2 shows a schematic diagram showing different type of bearers inthe 3GPP architecture according to the 3GPP standard.

FIG. 3 shows a flow chart of a voice service provision procedure,according to an embodiment of the invention.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

The present invention may be embodied in other specific devices, systemsand/or methods. The described embodiments are to be considered in allrespects as only illustrative and not restrictive. In particular, thescope of the invention is indicated by the appended claims rather thanby the description and figures herein. All changes that come within themeaning and range of equivalency of the claims are to be embraced withintheir scope.

In the present text, the terms “terminal” and “user equipment” are goingto be used indistinctly to refer to the same concept, the communicationsterminal used by an end user (i.e. a subscriber) of the mobiletelecommunications network to communicate over it. This terminal or userequipment may include any device capable of transmitting and receivingdata (e.g., voice, text, images, and/or multimedia data) over the mobilecommunications network. For example, the terminal may be a mobiletelephone, a smart phone, an electronic notepad, a personal digitalassistant (PDA), a tablet, a laptop, a personal computer...

The present invention proposes a technique for providing voice serviceto a terminal in a mobile communications network based on the expectedquality of service.

Said mobile communications network can be any type of mobilecommunications network (as for example 2G, 3G, 4G, 5G, LTE networks . .. ).

Nowadays, it is normal that a single mobile communications operator havedifferent inter-connected networks using different technologies (2G, 3G,4G, 5G, LTE networks). In other words, the mobile communications networkof a single network operator can be seen as a network includingdifferent inter-connected networks using different technologies (2G, 3G,4G, 5G or LTE). That is, the mobile communications network of a singleoperator comprises cells using different types of Radio AccessTechnology (e.g. LTE based RAT, 3G based RAT, 2G based RAT).

In an embodiment, the mobile communications network is configured toidentify expected call quality (directly or through a service parameterindicative of said expected quality) of a voice call (for example on a“per cell” or “per terminal” basis) and, if the expected call quality isabove a threshold, enable the call, either “per cell” (e.g. at the RNC)or “per user equipment (per subscriber)” (e.g. at the HSS).

In an embodiment, said voice call is a VoIP over HSPA call and if theexpected call quality is below a threshold (e.g. the service parameterindicative of said expected call quality is below a threshold), VoIPcalling over HSPA is disabled (i.e. allowing only circuit switchedcalling).

In an embodiment, for a terminal making a VoLTE call and undergoing acell handover to 3G, the network is configured to, if expected callquality is below a threshold, disable VoIP over HSPA (for a subscriberor for a whole cell) at the network. The network may also be configuredto identify the expected call quality based on previous VoIP over HSPAcall quality (again, either in that cell or based on previous calls bythe terminal).

In other words, the cases in which the voice service cannot be deliveredwith sufficient quality should be detected and more specifically, thecases in which the VoIP over HSPA (briefly called VoHSPA) service cannotbe delivered with sufficient quality should be detected.

As stated before, the detection of the expected quality (e.g., theobtainment of the service parameter indicative of said expected callquality) may be performed in 2 different ways (in 2 different levels),per cell or per subscriber:

-   -   Per cell: In this case the expected quality may be identified by        detecting the high congested cells (that is, the service        parameter indicative of the expected quality is the congestion).        In case that a high congested cell is detected any VoIP over        HSPA service in the cell is directly disabled (to do so the        Radio Network Controller, RNC in charge of the cell does not        enable the voice over IP over HSPA for said cell, so it will not        be possible to provide this service in then cell). In order to        detect congestion, many different procedures known from the        prior art can be followed. For example, the congestion detection        could be performed through traditional specific counters for        traffic, congestion, power, interference, radio connection        failures or a combination of them. The congestion of power in        the power amplifiers and the Uplink interference received can be        detected by the base station directly (and then reported to the        RNC). The congestion can be detected at the RNC that manages all        the RRC (Radio Resource Connection) connections with all the        UEs, either by direct measuring of the specific counters        previously mentioned or by receiving the reports from other        nodes as for example, the base stations. If the RNC detects a        high congestion situation in a certain cell, it will not enable        the VoIP over HSPA in the high congested cell. This can be done        for example, by changing a cell parameter in the RNC that        indicates the possibility (or not) of doing VoHSPA call in said        cell.        So, for example, congestion is detected because the uplink        Interference is higher than a threshold (e.g. −97 dBm) then the        VoHSPA service is disabled in that cell for any of the future        setup calls or for the current calls coming from VoLTE service,        because the quality of service expected during the congestion        phase will not be appropriated (the low throughput and big delay        will affect the MOS, Mean Opinion Score, of the Voice quality).

In an embodiment, the expected quality (e.g. the congestion detection)can be calculated for every cell of the mobile communications network(for example, every certain time period or triggered when the congestionis above a certain threshold, which is an event that can happen at anytime.). In a second embodiment, the expected quality is calculated byrequest, so only if calculated for a cell if it is requested by thenetwork (for example because a VoIP over HSPA is going to be establishedin said cell).

Also the expected quality at cell level, can be calculated by monitoringKPIs (drop call rate, failures, rejects, latency, throughput . . . ) ofother PS services for subscribers being served by the cell. And,according to said KPIs, it will be decided if the expected quality isbelow a threshold and so, the VoHSPA service is disabled for said cell.

-   -   Per terminal (or subscriber—also called subscriber 3G quality in        3G networks). When a subscriber (using a certain terminal) is        suffering a bad quality in VoIP over HSPA (e.g. the quality is        below a certain threshold), then it should be necessary to stop        said service and offer the standard Circuit Switched voice        service for said subscriber.

In order to detect the bad quality situation, many different proceduresknown from the prior art can be followed.

In an embodiment, to measure the quality at least one of the followingKPIs (Key Performance Indicators) or a combination of them is used as aservice parameter indicative of the expected quality (of course otherknown KPIs may be used as well):

-   -   Drop call rate ratio.    -   Call Setup Failure ratio    -   MOS (Mean Opinion Score)    -   Throughput    -   Latency

The quality offered in the last N VoIP over HSPA calls (being N a designparameter) for said subscriber (for said terminal) may be used tocalculate the service parameter indicative of the expected quality. Forexample, the expected throughput will be calculated as the averagethroughput of N last calls and if said averaged throughput is below acertain threshold the expected quality for the next call will beconsidered as “bad” or for example if more than 25% of the N last callshas been dropped, the expected quality for the next call will beconsidered as bad. All these KPIs can be measured at the RNC and theexpected quality for the subscriber may be also calculated in the RNC.If the expected quality is below a threshold, the RNC will mark saidsubscriber in the HSS as “no VoHSPA” as it will be explained later.

So, for example if the customer has done 4 VoHSPA calls and 2 of themwere dropped (reaching 50% call drop rate), the VoHSPA service isdisabled for that customer, so that the next call will be done withnormal CS voice service. Or another example, if the latency of thepackets start to increase, the VoHSPA service is disabled so that thenext call will be done with CS voice service.

In this case, the bad quality detection per subscriber is not possibleusing traditional counters (which are given per cell / NodeB / RNC andnot per subscriber). The process used to calculate the expected qualitycould vary depending whether real time detection is required by theoperator (or in other words, whether the operator requires reacting veryfast to bad quality scenarios or not):

-   -   Real time calculation process can be done through a tool sited        between Radio Access Network (RAN) and Core domains which        correlate Radio (RNC) and Core (Iu-PS) traces in a synchronised        way providing quality descriptive service-based KPIs per        subscriber. The optimum place is to integrate this function in        the RNC because all the information is passing through this        node. As stated before, the quality measured in the last N VoIP        over HSPA calls for said subscriber is used to calculate the        expected quality. Using real-time processing the bad quality        scenarios will be detected almost immediately.    -   In the second case (no real time), trace recording and        post-processing in a platform outside the RNC should be        sufficient using data from the RNC. The traces of all the        subscribers and all the cells are taken and saved in an external        server with a processing tool to calculate the KPIs mentioned        before per subscriber. As before, the quality measured (using        the KPIs) in the last N VoIP over HSPA calls for said subscriber        is used to calculate the expected quality. In this case (no real        time processing with an external server) the bad quality        scenarios will be detected with much more delay than in the real        time scenarios (usually a minimum of 15 minutes of delay).

Moreover this quality detection can be combined with the subscriberlocation information, so that the bad quality situation (for example,high numbers of dropped calls) can be associated with an area andconsider that if the subscriber changes the location, then maybe thequality will be better, but if the subscriber stays in the samelocation, the quality will be likely bad and it is better to maintaindisabled VoHSPA. The location can be obtained from GPS of the UE or theTiming Advance measurements received by the base station. The detectioncan be also associated with some specific radio conditions, consideringthis is the reason of the bad quality. The radio conditions indicatorsmay be one or both of the following measurements:

-   -   RSCP: Received Signal Code Power.    -   EcNo: The Ec (RSCP)/No (RSSI—total receive power) is the        received energy per chip divided by the power density in the        band.

In an embodiment, the expected quality is calculated for everysubscriber of the mobile communications network (for example, everycertain time period). In a second embodiment, the expected quality iscalculated by request, so only if calculated for a subscriber if it isrequested by the network (for example because a VoIP over HSPA is goingto be established for said subscriber).

Once a bad quality situation for a subscriber has been detected asexplained above (e.g. the expected quality is below a certainthreshold), the VoHSPA service is disabled for said subscriber. In orderto do that, for example, said information for said subscriber can bestored in the Home Subscriber Server, HSS of the 3G mobile communicationnetwork (or in the Home Location Register in older mobile communicationsnetwork) as a further attribute for said subscriber. That is, in the HLRor HSS, it is possible to define which services the subscriber issubscribed to; so it can be stored in said node that the VoIP over HSPAis not allowed for a certain subscriber. When a node network wants toknow if a Voice over IP over HSPA call can be established for said user,it simply must query the HSS.

Two different implementation scenarios depending on the call setup arepresented now: one for the voice setup in LTE and another one with thesetup in 3G.

Call setup using LTE Radio Access Technology

If the call setup for Voice over IP is done in LTE, then the networkwill allocate a VoLTE call with full quality of service assured, whichis available in the LTE networks. So the need of performing a handoverto other network will appear only in case of mobility to a zone withpoor LTE coverage or in case of high LTE load. In both cases, thedecision to handover to VoIP over HSPA is up to the LTE base station(called eNode B) which is serving the call in the LTE network.

-   -   If the handover target cell (using 3G Radio Access Technology),        has been configured as not enabling VoHSPA (e.g. by the RNC as        explained in the previous paragraph) because the quality of VoIP        over HSPA in the target cell is bad (e.g. the congestion is        above a certain threshold) then an SRVCC handover to 3G CS or 2G        CS is triggered. The performance of an SRVCC handover to 3G CS        or 2G CS is an standard feature known from the prior art. In        this case there will be a change in the Core network domain (CS        MSC versus PS IMS network) and signaling (traditional CS        Signaling versus SIP signaling).

The information of the configuration of VoHSPA in the 3G cell (if it isenabled or not) is obtained by the LTE network from the RNC controllingthe 3G target cell. This can be done by a direct query from the e-nodeBto the RNC or for example, using the known procedures for obtainingtarget cell features or configuration information of the SRVCC handoverdefined by the standard (TS 23.216 Single Radio Voice Call Continuity(SRVCC);Stage 2). Even there are some specific references in thisdocument about the determination of the neighbour cell list and the VoIPcapable and incapable cells.

-   -   If the handover 3G target cell, has been configured as enabling        VoHSPA (because the quality of the target cell is fine, e.g. the        congestion is below a certain threshold so VoHSPA is enabled)        then the subscriber VoHSPA enablement is checked in the HSS:        -   If the subscriber 3G quality detection is fine and therefore            the VoHSPA is enabled in the HSS (or HLR), a PS handover            from VoLTE to VoHSPA is performed, all in the PS domain.        -   If the subscriber 3G quality detection is not ok and,            therefore, the VoHSPA is not enabled in the HSS for said            subscriber, then a SRVCC handover to 3G CS or 2G CS is            triggered.

Summarizing, when a VoLTE call has been established using LTE Technology(301) and the network wants to handover (due to lack of coverage or highLTE load) the VoLTE call in a user equipment to a target cell using asecond Radio Access Technology (e.g. 3G) (302) the following steps areperformed (see FIG. 3):

-   -   A LTE network entity (e.g. the e-node B) checks if the VoHSPA is        enabled in the target cell (303) and if VoHSPA calls are enabled        for said subscriber (304).    -   If VoHSPA is not enabled in the cell and/or for the subscriber,        a SRVCC handover of the call (305) to a Circuit Switched voice        call (using 3G or even 2G Radio Access Technology) (306) is        performed.    -   If VoHSPA is enabled for both the cell and the subscriber, then        a PS handover (307) is triggered from a VoLTE service in the LTE        network to a VoHSPA call (308) in the 3G network in the target        cell is triggered.

In this scenario (namely, the call being set up using LTE Radio AccessTechnology), usually the radio part of LTE (the e-node B) is thedecision point to control the VoLTE handover to 3G CS or to 3G PS, andtherefore the allowance of the handover to VoIP PS 3G call. As explainedbefore, the e-node B will obtain the information about whether the 3Gcell is VoHSPA enabled (e.g. from the RNC of the 3G network) and it willobtain as well the subscriber information about whether the subscriberis VoHSPA enabled from the MME.

As explained before, similar to the case of the call setup done in 3G,when there is an expected bad quality of the VoHSPA session for asubscriber, then the VoHSPA is disabled for said subscriber in the HSSwith a command line sent to the HSS to modify the parameter indicatingthe services to which said subscriber is enabled. Then the profile ofthe subscriber is downloaded from the HSS to the MME and the eNodeB canobtain has the information directly from the MME. Then the eNode B cantake the proper decision with the information provided.

The procedure to perform a PS handover from VoLTE to VoHSPA or fromVoLTE to a CS call is known from the prior art.

Call setup using 3G Radio Access Technology

In case the VoIP over HSPA is setup in a 3G network, then it is notpossible to make the change of technology during the call (in otherwords, it is not possible to decide which is the best technology duringthe call). However, a decision can be taken for the next call.

In this case, if the expected quality for a user is bad (determined KPIsof success rate are below a threshold), then this service isautomatically disabled in the HSS by a command sent from the RNC forsaid user, so the next call for said user will not be a VoHSPA call.

Analogously, if the subscriber is being served by a cell with VoHSPAdisabled due to the congestion detected in that cell, then no VoHSPAcall is established in said cell.

So, when a subscriber is going to establish a voice call in a 3G cell(309), it is checked if VoHSPA service is enabled in the serving cell(310) (this is checked in the RNC controlling the cell) and for saidsubscriber (311) (this is checked in the HSS). If so then the call couldbe established using VoHSPA (312, 308). Otherwise the call would beestablished (313, 306) using circuit switched technology. In those caseswhere the terminal is only allowed to perform Circuit Switched calls(the Packet Switched, PS, service is disabled), and a PS call isinitiated towards the terminal, the mobile communications network,according to its capabilities will refuse or allow the call (it ispossible to have a PS call in one terminal and CS call in anotherterminal with a Gateway function in the IMS network).

In some terminals, two buttons are implemented, one for CS calls and onefor PS calls. Then if the terminals (originating or terminating thecall) is not able to do a PS call (because it is disabled for saidterminal), then the PS button will appear shadow (impossible to use,with no action). Generally speaking, when there is a button dedicated toPS calls, this is only working when the other terminal and the networkcan do PS calls.

In both scenarios (the call being set using LTE radio access networktechnology or using 3G radio access network technology), once the ‘badquality’ status has been triggered and the VoHSPA service has beendisabled (either for a whole cell or for a single subscriber) isimportant to specify when to enable again the service.

-   -   Cell Case: When the cell congestion was the trigger point, then        once the congestion in the cell is below a certain established        threshold, the VoHSPA is enabled automatically for the        subscribers in the cell. This may be just a change in the cell        parameter, located in the RNC, that activates the possibility of        doing VoHSPA calls.

As stated before, the RNC will detect a high congestion situation in acertain cell. So it will be the RNC, the node that, once the highcongestion situation is gone, it enables again the VoIP over HSPA in thecell.

-   -   Terminal/subscriber case: As stated before, the        subscriber/terminal quality can be associated to a certain        location or to certain radio conditions, so if the        terminal/subscriber expected quality was the reason to disable        the VoHSPA, then this is not anymore valid if the radio        conditions or the location of the terminal/subscriber have        changed. So, if the subscriber (and therefore the terminal used        by the subscriber) has changed to a location with acceptable        radio conditions or the user location has not changed but the        radio conditions have improved significantly in the same area        (in other words, the expected quality is above a certain        threshold), the VoHSPA service will be enabled again. That is,        the information in the HSS (or the HLR) will be changed so now        the subscriber using the terminal will be enabled for VoHSPA.        When the VoHSPA service is disabled for a user due to bad        quality conditions, a timer can be set to enable again the        service (i.e. to enable again the VoHSPA service in the HSS). Or        a timer can be set and when said timer expires, the expected        quality is again calculated (as explained before, for example,        monitoring KPIs as drop call rate, failures, rejects, latency,        throughput . . . ) to see if the radio conditions have improved        or not.

The presented embodiments improve the VoIP service performance in mobiletelecommunication networks solving the problems of current VoIPservices, providing to the user a good quality, especially in lowcoverage or congestion scenarios.

Even though most of the embodiments shown are referred to qualitydetection in Voice over HSPA services, the present invention is notlimited to this type of voice services but it can be applied to othertypes of voice services.

In this text, the word “comprises” and variants thereof (such as“comprising”, etc.) must not be interpreted in an excluding manner,i.e., they do not exclude the possibility that what has been describedmay include other elements, steps, etc.

A person of skill in the art would readily recognize that steps ofvarious above-described methods can be performed by programmedcomputers. Herein, some embodiments are also intended to cover programstorage devices, e.g., digital data storage media, which are machine orcomputer readable and encode machine-executable or computer-executableprograms of instructions, wherein said instructions perform some or allof the steps of said above-described methods. The program storagedevices may be, e.g., digital memories, magnetic storage media such as amagnetic disks and magnetic tapes, hard drives, or optically readabledigital data storage media. The embodiments are also intended to covercomputers programmed to perform said steps of the above-describedmethods.

The description and drawings merely illustrate the principles of theinvention. Some preferred embodiments of the invention are described inthe dependent claims which are included below.

Although the present invention has been described with reference tospecific embodiments, it should be understood by those skilled in theart that the foregoing and various other changes, omissions andadditions in the form and detail thereof may be made therein withoutdeparting from the scope of the invention as defined by the followingclaims.

Furthermore, all examples recited herein are principally intendedexpressly to be only for pedagogical purposes to aid the reader inunderstanding the principles of the invention and the conceptscontributed by the inventor(s) to furthering the art, and are to beconstrued as being without limitation to such specifically recitedexamples and conditions. Moreover, all statements herein recitingprinciples, aspects, and embodiments of the invention, as well asspecific examples thereof, are intended to encompass equivalentsthereof.

It should be appreciated by those skilled in the art that any blockdiagrams herein represent conceptual views of illustrative circuitryembodying the principles of the invention. Similarly, it will beappreciated that any flow charts, flow diagrams, state transitiondiagrams, pseudo code, and the like represent various processes whichmay be substantially represented in computer readable medium and soexecuted by a computer or processor, whether or not such computer orprocessor is explicitly shown.

1. A method of controlling provision of a voice service for a terminalin a mobile communications network, the method comprising: determining,based on service parameter associated with a first type of voice servicein the mobile communications network, whether to enable use of the firsttype of voice service for the terminal.
 2. A method according to claim1, wherein said service parameter is associated with at least one cellof the mobile communications network, and wherein the method furthercomprises: disabling, at the at least one cell, the first type of voiceservice when the service parameter is indicative of insufficientexpected quality of service for the terminal in the event of use of thefirst type of voice service by the terminal.
 3. A method according toclaim 2, further comprising: providing a second type of voice servicefor the terminal when the first type of service is determined to bedisabled.
 4. A method according to claim 1, wherein the serviceparameter is associated with the terminal, and wherein the methodfurther comprises: disabling, at the terminal, the first type of voiceservice when the service parameter is indicative of insufficientexpected quality of service for the terminal in the event of use of thefirst type of voice service by the terminal.
 5. A method according toclaim 4, further comprising: providing a second type of voice service atthe terminal when the first type of service is determined to bedisabled.
 6. A method according to claim 1, wherein the serviceparameter for the first type of voice service is a quality parameterassociated with at least a part of the mobile communications network. 7.A method according to claim 1 wherein said the first type of voiceservice is a Voice over Internet Protocol, IP, over High Speed PacketAccess, HSPA service.
 8. A method according to claim 3, wherein thesecond type of voice service is a voice over CS service.
 9. A methodaccording to claim 1, wherein, in the event of a handover from a firstcell of the mobile communications network to a second cell of the mobilecommunications network, the method further comprises: switching acurrent voice service to the first type of voice service if the firsttype of voice service is enabled at the second cell and/or at theterminal.
 10. A method according to claim 2, wherein, in the event of ahandover from a first cell of the mobile communications network to asecond cell of the mobile communications network, the method furthercomprises: switching a current voice service to a second type of voiceservice if: (i) the expected quality of service for the terminal in theevent of use of the first type of voice service by the terminal isinsufficient; or (ii) the first type of service is disabled at thesecond cell.
 11. A method according to claim 9, wherein the first celluses a first Radio Access Technology (RAT) and the second cell uses asecond RAT.
 12. A method according to claim 11, wherein the first RAT isan LTE-based RAT, the second RAT is a 3G-based RAT.
 13. A networkelement or a system for controlling provision of a voice service for aterminal in a mobile communications network, the network element or thesystem being configured to: determine, based on an service parameterassociated with a first type of voice service in the mobilecommunications network, whether to enable use of the first type of voiceservice for the terminal.
 14. A network element or a system forcontrolling provision of a voice service for a terminal in a mobilecommunications network, the network element or the system beingconfigured to determine, based on an service parameter associated with afirst type of voice service in the mobile communications network,whether to enable use of the first type of voice service for theterminal, the network element or the system is further configured toperform the steps comprising: (a) determining, based on serviceparameter associated with a first type of voice service in the mobilecommunications network, whether to enable use of the first type of voiceservice for the terminal, wherein said service parameter is associatedwith at least one cell of the mobile communications network; and (b)disabling, at the at least one cell, the first type of voice servicewhen the service parameter is indicative of insufficient expectedquality of service for the terminal in the event of use of the firsttype of voice service by the terminal.
 15. A computer program comprisingcomputer program code means suitable for performing the steps of themethod of claim 1 when the aforementioned program is executed in acomputer, a digital signal processor, a field-programmable gate array, aspecific integrated circuit of the application, a microprocessor, amicrocontroller or any other form of programmable hardware, included ina distributed manner.
 16. A terminal for use in a system for controllingprovision of a voice service for a terminal in a mobile communicationsnetwork, the network element or the system being configured todetermine, based on an service parameter associated with a first type ofvoice service in the mobile communications network, whether to enableuse of the first type of voice service for the terminal, said terminalcomprising at least one functionality configured for determining, basedon service parameter associated with a first type of voice service inthe mobile communications network, whether to enable use of the firsttype of voice service for the terminal.